Many different computing systems are available today, but most of these systems are built around fundamental components such as those illustrated in FIG. 1. Typically, a computer system 20 includes a central processing unit 10 (CPU), which is connected through an input bus 11 to an input module 12 and through an output bus 13 to an output module 14. CPU 10 is also connected through data buses 15, 16 to a memory unit 17.
CPU 10 provides control and computing functions. Input and output modules 12, 14 are used to communicate between the computer user and CPU 10. Input module 12 supplies information to CPU 10. Typical input devices are a keyboard and a mouse. Output module 14 displays information from central processing unit 10. Typical output modules include video display monitors, printers, plotters and other visual display means. Input unit 12 and output unit 14 are frequently referred to as input/output (I/O) units.
Memory unit 17 typically contains two general types of information, instructions and data. A computer program is a sequence of instructions that are executed by the computer to perform a specific function. Data in memory unit 17 are processed by CPU 10 in response to the instructions from a computer program which is executing in CPU 10. An executing computer program is called a computer process.
Memory unit 17 typically includes mass memory 17A, sometimes called secondary memory, and main memory 17B. Main memory 17B is usually used to store at least a portion of a program currently being executed by CPU 10 and data required by the program. Mass memory 17A, e.g. magnetic disk or tape, is used to store programs, data, or portions of either programs or data which are not needed immediately by CPU 10 or which cannot be accommodated in main memory 17B because of size limitations of main memory 17B.
The operating system of a computer is a computer process which coordinates operation of CPU 10, I/O devices 12, 14 and 17A and main memory 17B and which provides an interface between user applications (defined below) and computer hardware. As is used herein, the term computer hardware refers to the physical components of the computer system. As an operating system is necessary for the orderly operation of a computer system, the operating system is loaded into main memory 17B and executed during power up of the computer system (a process called "booting") and remains in main memory 17B and in execution until the computer system is ultimately deactivated.
A user application generally refers to a computer process which executes in addition to, and is generally considered distinct from, the operating system. A user application begins at some point in time as source code, i.e., computer instructions in a form intelligible to human beings. This source code is translated or "compiled" into object code, which is a form intelligible to computer system 20, particularly CPU 10. Several object code modules may be linked to form a single executable image, which is in a form which can be processed by CPU 10 of computer system 20. The program is executed by copying the executable image into main memory 17B and instructing CPU 10 to carry out the instructions, one by one, of the executable image. As stated above, a computer program in such state of execution is called a process.
The instructions executed by a process executing within computer system 20 generally manipulate the resources of computer system 20. For example, instructions can manipulate data stored in mass memory 17A, accept data from input module 12 or display data on output module 14. Some processes, which are designed to execute on a first computer system, are configured to issue computer instructions which manipulate resources of a second computer system.
It is well-known in the art of computer communications to connect two or more computer systems such that data can be transferred between two or more computer systems. Two or more computer systems so connected are collectively called a "network". In such a network, each computer system treats each other computer system as an I/O device to which data can be sent and from which data can be received.
A first process executing on a first computer system can issue instructions to a second process executing on a second computer system. The second process then manipulates the resources of the second computer system in accordance with the instructions received from the first process. The second process is called a "server" process because the second process provides a service to the first process, which is called a "client" process. The service provided is the manipulation of resources of the second computer system.
Many computer communication systems implement what is called "remote procedure calling". In remote procedure calling, a client process, which is executing on a first computer system and which seeks to manipulate data on a second computer system, requests action through a server process, which is executing on the second computer system and which manipulates data in response to requests from the client process. The server process performs any of an inevitably finite list of operations on behalf of the client process. Often it is the case that the precise function requested by the client process is not among the particular operations performed by the server process. To perform a function for which no server process operation is defined requires several requests to and responses from the server process that require substantial use of communications media which in turn involves considerable expense and time.
Logic flow diagram 200 (FIG. 2A) illustrates an example of remote procedure calling. Logic flow diagram 200 is described in the context of computer systems 20A and 20B (FIG. 2B), which are interconnected through network 256. Suppose a client process 252 on computer system 20A is to delete all files on computer system 20B whose names match a given pattern, e.g., file names ending in ".TMP", and which have not been modified in at least 30 days. Client process 252 sends to server process 254 which is executing on computer system 20B a request to list all files in step 21 (FIG. 2A). Arrow 260 (FIG. 2B) represents that request. Processing transfers from step 21 (FIG. 2A) to step 22 in which client process 252 (FIG. 2B) receives the list from server process 254, as shown as arrow 262. Steps 21 and 22 (FIG. 2A) involve two transfers across network communications media.
Double rectangles in FIGS. 2A and 3A indicate information transfer across network 256 (FIG. 2B). Whereas execution of an instruction within either computer 20A or computer 20B takes between several nanoseconds to several microseconds, transfer of information across network 256 generally takes seconds or minutes depending on the configuration of network 256 and on the amount of information. In some networks, transfer of a large amount of data can take an hour or more.
Processing transfers from step 22 (FIG. 2A) to for each filename step 23. For each filename step 23 and next steps 23a, 23b and 23c define a loop within which each filename of the list of filenames is processed by the client process. For each filename of the list, processing transfers from for each filename step 23 to a test step 24 in which client process 252 (FIG. 2B) compares the filename to a pattern. If the filename does not match the pattern, processing transfers from test step 24 (FIG. 2A) through next step 23a to for each filename step 23 and the next filename is processed.
Conversely, if the filename matches the pattern, processing transfers from test step 24 to step 25. In step 25, client process 252 (FIG. 2B) sends to server process 254 an instruction to provide the date that the particular file was last modified as shown by arrow 264. Processing transfers from step 25 (FIG. 2A) to step 26 in which client process 252 (FIG. 2B) receives from server process 254 the date requested as represented by arrow 266. Steps 25 and 26 (FIG. 2A) involve two more transfers across network communications media for each such matching filename.
Processing transfers from step 26 to a second test step 27 in which client process 252 (FIG. 2B) compares the date received with the current date less 30 days. If the date indicates that the file has been modified within the preceding 30 days, processing transfers from second test step 27 (FIG. 2A) through next step 23b to for each filename test step 23 in which the next filename is processed. Conversely, if the date indicates that the file has not been modified within the preceding 30 days, processing transfers from second test step 27 to step 28.
In step 28, client process 252 (FIG. 2B) sends to server process 254 an instruction directing server process 254 to delete the file from computer system 20B as represented by arrow 268. Processing transfers from step 28 to step 29 (FIG. 2A), in which client process 252 (FIG. 2B) receives from server process 254 acknowledgement of the deletion as represented by arrow 270. Thus, steps 28 and 29 (FIG. 2A) involve two further transfers across network 256 (FIG. 2B) for each file to be deleted.
Processing transfers from step 29 through next step 23C to for each filename step 23. If all filenames in the list have been processed, processing transfers from for each filename step 23 to terminal step 20b in which processing terminates. Thus, processing according to logic flow diagram 200 (FIG. 2A) requires a multitude of information transfers across network 256. Such heavy use of network communications media is both costly and time consuming.
An alternative approach to remote procedure calling is "remote programming". In remote programming, a process, which is called a "client process" and which executes on a first computer system, sends to a server process executing on the second computer system a list of instructions. The instructions are then carried out by the server process effectuating the goal of the client process. The instructions which the server process is designed to carry out must have some degree of generality; i.e., the instructions must provide some degree of decision-making capabilities.
Logic flow diagram 300 (FIG. 3A) illustrates an example of remote programming. To effectuate the example given above with respect to FIGS. 2A and 2B in a remote programming environment, client process 352 (FIG. 3B) in step 31 (FIG. 3A) builds a program whose instructions are represented by logic flow diagram 31-P. Logic flow diagram 31-P is described below.
Processing transfers from step 31 to step 32, in which the program is transferred to computer 30B (FIG. 3B) through network 356 as represented by arrow 358. Processing transfers from step 32 to step 33 (FIG. 3A) in which the program is executed within computer 30B. During execution, the program is process 352A (FIG. 3B) within computer 30B. The instructions of program 352A are executed according to logic flow diagram 300.
In step 31-B (FIG. 3A), a list of filenames is created. Processing transfers from step 31-B to for each filename step 31-C. For each filename step 31-C and next steps 31-H, 31-I, and 31-J form a loop within which each filename in the list of filenames is processed. For each filename, processing transfers from for each filename step 31-C to test step 31-D in which the filename is compared to a pattern. If the filename does not match the pattern, processing transfers from test step 31-D through next step 31-H to for each step 31-C. Conversely, if the filename matches the pattern, processing transfers from test step 31-D to step 31-E.
In step 31-E, process 352A retrieves the date of last modification of the file having the filename. Processing transfers from step 31-E to a second test step 31-F in which the date is compared to the current date less 30 days. The date of last modification of the file is retrieved from server process 354 (FIG. 3B). If the date of last modification is more recent than the date of 30 days prior, processing transfers from second test step 31-F (FIG. 3A) through next step 31-I to for each filename step 31-C. Conversely, if the date of last modification is prior to the date of 30 days prior, processing transfers from second test step 31-F to step 31-G. In step 31-G, the file is deleted by issuing an appropriate instruction to server process 354 (FIG. 3B). Processing transfers from step 31-G (FIG. 3A) through next step 31-J to for each filename step 31-C. If all filenames in the list have been processed, processing transfers from for each filename step 31-C to terminal step 31-K in which process 352A terminates. As indicated by arrows 360 (FIG. 3B), all interaction between process 352A and server process 354 transpired entirely within computer 30B without use of network 356.
After successful completion of the program, processing transfers from step 33 to step 34 (FIG. 3A) in which server process 354 (FIG. 3B) reports to client process 352 that the program completed successfully as represented by arrow 362. Note that this remote programming procedure involves only two uses of network communications media: a first to send the program or list of instructions to server process 354 as represented by arrow 358 and a second to receive from server process 354 notification of successful completion of the program as represented by arrow 362. Note also that client process 352 was able to request of server process 354 an operation not explicitly provided by, and perhaps not even anticipated by the developers of, server process 354.
However, remote programming encounters the same inefficiencies of remote procedure calling when a computer process seeks to coordinate manipulation of data on two or more computer systems. For example, a process on computer X may seek to delete all files on computer system Y or computer system Z which have the same name, date of last modification and size as any file on computer X. Since server process 354 described above with respect to FIGS. 3A and 3B is capable of directly manipulating resources on the computer system on which the server process is executing, i.e. computer system Y, the server process is unable to coordinate data management spanning more than one computer system without producing the inefficiencies discussed above in conjunction with remote process calling.
An improvement over remote programming is described by C. Daniel Wolfson, et al., "Intelligent Routers", 9th International Conference on Distributed Computing Systems at pp. 371-375 (1989). Wolfson et al. disclosed a system wherein a process could move from one computer system to another within a network. The process directed its own movement through the network by issuing an instruction whose execution caused the process to be moved. The instruction specified to which computer system the process was to be moved.
However, the solution in the form disclosed in Wolfson et al. was of limited functionality. Processes were required to be configured to comport with the specific requirements of the computer system to which the respective processes moved. Processes were not able to communicate with one another; processes instead directly stored or directly retrieved data from the mass memory of the computer system within which the respective processes were executing. One process could only interact with another process only if both processes knew the precise location within mass memory where messages were to be stored and/or retrieved.
The system disclosed by Wolfson et al. did not provide any security. Thus, to the extent that the Wolfson et al. system allowed one process to interact with another process, a malicious process could interfere with the execution of a second process. In addition, the set of instructions provided to processes of the system disclosed by Wolfson et al. was very limited; only character string data and numerical data representing real numbers were provided for.
Another system similar to that disclosed by Wolfson et al. was that described by D. Tsichritzis et al., "KNOs: KNowledge Acquisition, Dissemination, and Manipulation Objects", ACM Trans. on Office Information Systems, vol. 5, no. 1, pp. 96-112 (1987). The system described by Tsichritzis et al. added to the system described by Wolfson et al. the generality of object-oriented programming.
Object-oriented programming organizes data and instructions into "objects" in which data represent the "state" of an object and instructions are grouped into tasks or "operations" that the object can "perform". Object-oriented programming represents a very useful conceptual framework in which problems solved by a computer may be more easily reduced to a series of computer instructions.
Objects created in an object-oriented environment are grouped into classes. Objects of a class have states of the same structure and perform the same operations. The system disclosed by Tsichritzis et al. did not provide for the mobility of class definitions; therefore, objects of a given class created within the environment described by Tsichritzis et al. could only travel to those computer systems for which the given class was defined. Additionally, objects in the environment described by Tsichritzis et al. were represented in a form that required that the computer systems of the network, within which objects could travel, were homogeneous.
The system taught by Tsichritzis et al. further described an instruction by which a first process, i.e., a "head" process, could create copies of itself. The copies were called "limbs". Tsichritzis et al. taught that limbs could be sent to remote computer systems at the direction of the head process. However, the limbs were not active; the computer instructions of a limb were executed only at the direction of the head process. Directing the activity of a limb process positioned in a remote computer system required that the head process issue commands to the limbs across network communications media, involving considerable time and expense in large networks.
Further inefficiencies were found in the system taught by Tsichritzis et al. when a small computer, e.g., a personal computer, was connected to a large network through a large computer, e.g., a mainframe computer. For example, to send many limbs to various computers of the network, the small computer was required to send many identical limbs between the small computer and the large computer. As limbs, which are copies of the head process, could be quite large, inefficiencies in such a system could have been quite substantial.
Tsichritzis et al. taught a system wherein a first process communicated with a second process by giving to the second process a reference to the first process. A reference is data which identifies an object and which grants access to the object identified. As the second process contained a reference to the first process, the second process could request that the first process execute specific computer instructions which were contained within the first process. However, as the first process provided the second process with a reference to the first process without simultaneously obtaining a reference to the second process, the second process had access to the first process and the first process did not have reciprocal access to the second process. Such a system permitted a "malicious" process, i.e., a process designed by a malicious programmer or inadvertently designed to harm other processes, to gain access to a second process without granting reciprocal access.
Thus, in spite of the achievements of Wolfson et al. and Tsichristzis et al., neither discloses a system in which new classes of objects and processes can be created and can be transported to and processed by computer systems within the network which do not contain class definitions for the new classes. Neither does either Wolfson et al. or Tsichristzis et al. disclose a mechanism for implementing a complex and hierarchical security scheme. Furthermore, neither Wolfson et al. nor Tsichristzis et al. disclose computer processes which can interact with one another but which cannot gain access to other processes without granting reciprocal access.
Furthermore, neither Wolfson et al. nor Tsichristzis et al. disclose computer processes which can travel to several computer systems simultaneously by creating several autonomous clones of a process and transporting the clones to respective computer systems. The limbs taught by Tsichristzis et al. are not autonomous as the computer process controls the actions of limbs at remote computer systems. Furthermore, neither Wolfson et al. nor Tsichristzis et al. disclose efficient transportation of the clones to the respective computer systems in which transportation of redundant information across network communication media is minimized.